home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1642 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.1 KB  |  79 lines
  1. Newsgroups: comp.lang.c++
  2. Path: ncrgw2.ncr.com!ncrhub6!daynews!falcon!news
  3. From: Dick Menninger <Dick.Menninger@DaytonOH.ATTGIS.COM>
  4. Subject: Re: Difficulty hiring people with C++ experience.
  5. X-Nntp-Posting-Host: 149.25.99.44
  6. Message-ID: <DL1Dp5.H9z@falcon.daytonoh.attgis.com>
  7. Sender: news@falcon.daytonoh.attgis.com (News administrative Login)
  8. Reply-To: Dick.Menninger@DaytonOH.ATTGIS.COM (mennid)
  9. Organization: AT&T Global Information Solutions
  10. X-Newsreader: DiscussIT 2.5.1.3 for MS Windows [AT&T Software Products Division]
  11. References: <ALUN.CHAMPION.96Jan10160055@g7240065.bridge.bst.bls.com>
  12. Date: Thu, 11 Jan 1996 21:43:53 GMT
  13.  
  14.  
  15. > ==========Alun Champion, 1/10/96==========
  16. > 
  17. > In article <4d12p3$26lq@news.doit.wisc.edu>
  18. > keiter@hp-171.cae.wisc.edu (Eric Richard Keiter) writes:
  19. > 
  20. > : (Tom Donaldson) writes:
  21. > ::  When asked about
  22. > :: "programming by contract", the response is "Huh?"  The
  23.  
  24. [stuff deleted]
  25.  
  26. > : and what is programming by contract?  it sounds like an
  27. > obvious question
  28. > : -- is the answer not obvious?
  29.  
  30. > The contract between the user and its supplier is the set of
  31. > requests that
  32. > a user can make of that supplier. Programming by contract is the focus
  33. > of ensuring the supplier fulfils its contracts. Some aspects
  34. of the user
  35. > contract is enforced by the compiler like making methods private
  36. > or protected
  37. > but the ability to grant access for particular classes is not
  38. > possible at the
  39. > moment, so some reliance is on the user of the class to not
  40. > break its contract
  41. > with the supplier.
  42. > In a multi-threaded environment its very hard to guarentee the
  43. > contract between
  44. > user and supplier because the guarentee of the supplier can be
  45. broken by
  46. > another thread i.e. values changed etc.. In these situations
  47. you lock the
  48. > supplier so it can guarentee the contract for the period of that lock.
  49.  
  50. Well this might not have fully communicated the complete
  51. concept.  A contract provides the rules, invariants, rights
  52. and responsibilities of all parties involved.  It applies to
  53. functional interfaces that return stuff (e.g., the caller is
  54. responsible for destroying the stuff when done with it--
  55. is a contract part), as well.  The idea of contracts is to make
  56. all of the semantic properties and expectations more
  57. explicit and visible.  When a language includes mechanisms
  58. for specifying some of it, then more can be checked
  59. either at compile time or run-time.  A supplier could do
  60. some of this with ASSERT macros or statements in the
  61. supplier code, though the form may be less clear.
  62. But the user side is generally problematic to auto-verify.
  63. Worse, most of the contractual details the users needs
  64. to know are often undocumented, as well.  The more
  65. expensive bugs [bugs found late in testing and in released
  66. products] tend to be caused by poorly documented contracts
  67. or inconsistent contracts [it would be nice to have to state
  68. them in a way that most inconsistencies could be checked].
  69.  
  70. So, contracts are one place where program specification,
  71. program verification, automatic compile and run-time checking,
  72. and proof of correctness are likely to converge for significant
  73. subsets of software development.
  74.  
  75. Good Day
  76. Dick
  77. Dick.Menninger@DaytonOH.ATTGIS.COM
  78.  
  79.